Many networking technologies are in widespread use today, including Ethernet and related protocols (e.g., IEEE 802 standards), Fibre Channel, Enterprise-System Connection (ESCON), Infiniband®, Digital Video Broadcast—Asynchronous Serial Interface (DVB-ASI) and others. Such networking technologies can utilize performance counters. Performance counters provide data on various operating features of a network, and can thus enable remote monitoring and maintenance of the network.
To better understand various aspects of the embodiment described below, an exemplary conventional Ethernet type system will be described with reference to FIG. 13. A conventional system 1300 can include a media access controller (MAC) 1302, a remote monitoring (RMON) counter 1304, a serializer/deserializer (not shown) connected by a data path (SERDES), and a system bus (System 0 to System N).
In a conventional Ethernet type network, RMON counters are required for each media access controller (MAC). RMON counters are statistics counters for statistics provided by each MAC. Details regarding RMON counters are given in document RFC 2819 defined by the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG).
As is well understood, according to various data transmission protocols, including Ethernet type protocols, a link layer is a layer in any networking technology that sits approximately above the physical layer. In this document the term media access controller (MAC) and link layer can be considered essentially interchangeable. Also in this document, the term packet refers to a discrete unit of data and may be a packet, cell, frame or other unit of data carried in a network.
A typical transmit and receive Ethernet MAC device can use 32 counters. For a chip having several MACs, the operation of separately computing RMON counts for the statistics of each MAC can be expensive in terms of logic resources (gates) and hence result in undue increase in device size and/or introduce routing delays.
A first conventional approach to reducing the circuitry needed for computing RMON counts will now be described with reference to FIG. 14. A first conventional system 1400 can include a number of MACs 1402-0 to 1402-N, each of which can supply a statistic information vector (Statistics Vector0 to N) to an RMON processor block 1404. A statistics vector (Statistics Vector0 to N) can contain all the information required to update RMON counters for the MAC. Statistics information vectors (Statistics Vector0 to N) can be considered valid when a corresponding vector enable signal (Vector0 to N) is active.
For example, in an exemplary MAC (e.g., any of 1402-0 to 1402-N), there can be approximately 50 statistics related signals from a MAC transmit side to the RMON processor 1404. Further, there can be approximately 30 statistics related signals from MAC receive side to the RMON processor 1404.
Thus, it is understood that routing such numerous values for multiple MACs can introduce considerable wiring constraints and delays when implemented, as a large number of lines would have to be routed to a single RMON processor 1404.
FIG. 15 is a block schematic diagram of a conventional RMON processor such as that shown as 1404 in FIG. 14. An RMON processor 1500 can include an input buffer 1502-0 to 1502-N corresponding to each MAC, a multiplexer (MUX) 1504, an adder 1506, a statistics memory 1508, and an arbiter 1510.
Input buffers (1502-0 to 1502-N) can be relatively small sized buffers that can store statistics information coming from each MAC port. An arbiter 1510 can serve as an arbitration mechanism for reading data from input buffers (1502-0 to 1502-N) that helps ensure read data from one buffer does not overwrite read data from another.
In operation, a statistics memory 1508 can be read whenever statistics information is read from a corresponding input buffer (1502-0 to 1502-N). Memory read from a statistics memory 1508 can be added with data read from the corresponding input buffer (1502-0 to 1502-N) by operation of adder 1506. The resulting new value can then be written back into statistics memory 1508 to thereby store updated information.
In this way, a first conventional approach can multiplex statistics vectors to a single computing engine (i.e., adder and statistics memory) to thereby reduce a gate count needed to perform RMON count operations. However, a drawback to the conventional arrangement shown in FIGS. 14 and 15 can be the undesirably large amount of signal routing required to provide all statistics vectors and vector enable signals to a single RMON processor.
A second conventional approach to reducing the circuitry needed for computing RMON counts will now be described with reference to FIG. 16. A second conventional system 1600 can include MACs 1602-0 to 1602-N, a vector bus 1604, vector enable lines 1608, and an RMON processor 1610.
In the second conventional system 1600, a statistics vector from each MAC (1602-0 to 1602-N) can be WIRED-OR'd in order to deliver information to RMON processor 1610. In implementing such a WIRED-OR arrangement, outputs from each MAC (1602-0 to 1602-N) can be time-multiplexed through a shared vector bus 1604 instead of through separate buses for each MAC port. A shared vector bus 1604 can be a tri-statable bus where each MAC port can drives its output whenever enabled. This use of a shared vector bus can reduce the amount of routing going to a central location, but timing-wise, the arrangement can be less efficient if there is such a tristated bus going through all the MAC ports.
Disadvantages of the above-described conventional systems include the considerable routing needed to provide statistics information to a central location (e.g., RMON processor or simple network management protocol (SNMP) agent). This can lead to routing congestion and/or high power consumption. Further, because a significant number of statistics vector bits are required in a typical application, providing data paths for such a large number of bits can lead to high die area and increased routing and timing problems.
In light of the above, it would be desirable to have a mechanism of updating statistics counters for network devices that can have a single computing engine for multiple MACs, yet not suffer from the drawbacks of conventional arrangements, like those described above.
It would also be desirable to have a communication protocol between the MAC blocks and a statistics counter that could convey all the statistics counting related information with minimal routing overhead when compared with conventional approaches.